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Abstract 

We discuss a class of computer/network architec¬ 
tures that supports multilevel security while utiliz¬ 
ing commercial-off-the-shelf (COTS) workstations 
and COTS productivity software applications. We 
show that a property of these architectures is that, 
while supporting multilevel confidentiality policies, 
they do not generally support partially ordered in¬ 
tegrity policies: specifically, these architectures do 
not support the maintenance of data that is higher 
in integrity than the integrity level of the COTS 
components. 

1 Introduction 

Data integrity is defined as “the property that data 
has not been exposed to accidental or malicious al¬ 
teration or destruction.” [14] 

A person who has integrity is identified as being 
one who acts based on a set of internalized prin¬ 
ciples that are founded on a system of ethics. A 
person is reliable if others perceive them as avail¬ 
able and consistent. In contrast, high integrity in¬ 
formation is information that can be relied upon as 
the basis for critical decisions. An example will il¬ 
lustrate what we mean by information integrity. A 
company may store a trade secret in its information 
system. This trade secret is used on a regular ba¬ 
sis to manufacture the product. If the trade secret is 
subjected to malicious modification, the company’s 
product will be affected. Some trade secrets are: 
formulas used by chemical companies, a food ven¬ 
dor’s “secret sauce” or “classic” formula, and the 
closed source code of software vendors. 

High integrity information may be used to sup¬ 
port critical “intelligence” decisions. This may in¬ 
clude both government intelligence as well as cor¬ 
porate intelligence. Highly reliable information can 
also be used to determine the course of diplomatic, 
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military or corporate decisions. Another sector in 
which there is concern regarding information re¬ 
liability and integrity is in the area of consumer 
information. This includes financial, educational, 
health and other records. 

High assurance systems are intended to ensure 
the enforcement of policies to protect the confi¬ 
dentiality and integrity of information. The in¬ 
tent of this paper is to provide an overview of a 
subtle aspect of system security that is not often 
openly addressed by the developers of high assur¬ 
ance trusted systems: that is, a system can only 
be trusted to manage data whose integrity is at or 
below that of its weakest component. Some devel¬ 
opers may admit that the problem we characterize 
here is something “we have always known about,” 
yet for the consumers of these systems, the prob¬ 
lem may not be fully appreciated. Our premise is 
that builders of systems designed to provide high 
assurance enforcement of non-discretionary secu¬ 
rity policies often ignore the impact of component 
and architectural choices on the integrity of data 
that users intend to protect. Although the prob¬ 
lem is exacerbated in systems designed to imple¬ 
ment mandatory integrity models, such as the Biba 
model [6], it is implicit in systems intended to sup¬ 
port confidentiality policies. The former systems 
have explicit integrity requirements, whereas the 
latter may have implicit integrity expectations. 

The remainder of this paper is organized as fol¬ 
lows. Section 2 provides a review of concepts 
associated with confidentiality and integrity, and 
continues with a discussion of the challenges to 
integrity encountered in commercial productivity 
software. Section 3 follows with a description of 
a model architecture which we believe character¬ 
izes a wide variety of modern distributed secure 
systems. Several example systems are described. A 
description of integrity limitations in systems based 
on the model architecture is provided in Section 4. 
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Conclusions and discussion in Section 5 complete 
the paper. 


2 Background 

This section sets the context for the presentation 
of the model architecture and its attendant integrity 
limitations. 


2.1 Confidentiality and Integrity 

Confidentiality and integrity policies are often en¬ 
countered in complex systems and are sometimes 
not clearly differentiated. In the military sector, 
secret information is often treated as reliahle. Intel¬ 
ligence information of both high and low integrity 
is often handled as highly classified. Classification 
may be related to sources and methods. If the infor¬ 
mation is disconnected from its source, confiden¬ 
tiality may not be required, but a means of attesting 
for the reliability of the information is needed. 

A given piece of information will have a integrity 
value as well as a separate confidentiality value. 
This is the case whether or not the information 
has been explicitly associated with an integrity or 
confidentiality “label,” as is done in “multilevel” 
systems. These confidentiality and integrity values 
apply to code as well as data objects. 

The confidentiality value attributed to a da¬ 
tum may reflect the damage caused to the owner 
by unauthorized disclosure of the information; 
whereas the integrity value may reflect the damage 
caused by unauthorized modification of the infor¬ 
mation. For code, “integrity” carries the additional 
meaning that the code works the way it is supposed 
to, and performs no other, e.g. hidden, functions. 

Is there an example of information that is high 
confidentiality and low reliability? Potentially crit¬ 
ical information from an unreliable source might 
fall in this category. It may be held in strict confi¬ 
dentiality pending confirmation by a more reliable 
source. 

Information that is high integrity but low con¬ 
fidentiality might be “selected, well established 
facts.” For example, the Oxford English Dictionary 
is considered to be a highly reliable (and definitive) 
source for definitions of words used by English 
speaking peoples. 

Eow integrity and low confidentiality informa¬ 
tion might be the boasts of the children on the play¬ 
ground. 


As noted earlier, high confidentiality, high in¬ 
tegrity information could be a trade secret. 

The Biba model [6] is intended to describe an in¬ 
tegrity policy that ensures the protection of high in¬ 
tegrity entities (viz, abstractions of active subjects 
and passive objects) from corruption. This corrup¬ 
tion can occur by way of a high-integrity subject 
reading or executing low integrity data (thus cor¬ 
rupting the behavior of the subject), or by a low 
integrity subject writing to a high-integrity object 
(corrupting the value of the object). A proper im¬ 
plementation of the integrity policy will prevent 
these corruptions. 


2.2 Integrity of COTS Components 

There is a tension between integrity and productiv¬ 
ity in both the development and the acquisition of 
commercial computer systems. Eor development, 
fast time-to-market product cycles are in conflict 
with the type of methodical development processes 
capable of yielding high-integrity products. Eor ac¬ 
quisition, the desire for feature-rich ubiquitously- 
available software functionality is in conflict with 
the need to for products that have been carefully 
built to ensure security policy enforcement. 

Organizations find commercial software produc¬ 
tivity suites highly seductive because of the re¬ 
sulting productivity enhancement of the workforce. 
These productivity suites may include word pro¬ 
cessing, spread sheet, presentation, time manage¬ 
ment, and database tools. However, commercial- 
off-the-shelf (COTS) components^ both OS and 
application, are considered to be of low assur¬ 
ance.^ In the absence of universally recognized 
integrity labels, we will designate low assurance 
software components to have an implicit integrity 
label of low assurance. In Section 2.3 we describe 
a number of techniques that support the produc¬ 
tion of high integrity components. In general, rapid 
production of software in a time-to-market-driven 
economy discourages the application of these tech¬ 
niques. Two detrimental effects enabled by low 


*We define COTS components to be either unevaluated by 
independent third parties, or evaluated below Class B2/EAL5. 
113,3] 

^The evaluation classes below Class B2 and EAL5 do 
not require either substantial configuration management or 
code inspection for malicious artifacts during evaluation, 
and components in these classes are considered to he “low 
assurance.”[l 1] 



integrity production techniques are incorrect soft¬ 
ware functionality and subversive software arti¬ 
facts. As we will see, such low integrity software 
can have a negative effect on the data it handles. 

There is clear evidence that subversion of com¬ 
mercial software is more common than generally 
perceived. Entire websites [4] are devoted to de¬ 
scribing clandestine code which may be activated 
using undocumented keystrokes. Frequently this 
code merely provides an animated list of the soft¬ 
ware developers’ names. Sometimes these anima¬ 
tions are extremely elaborate as in the case of a 
flight simulator embedded in many versions of the 
Microsoft Excel spreadsheet software. That these 
“Easter Eggs” are merely the benign legacy of the 
programming team is perhaps a reflection of the 
general good intentions of the programmers. Ma¬ 
licious insertions are just as easily possible. 

An indication of the serious nature of the prob¬ 
lem was indicated in April 2000 when news reports 
created a mild hysteria surrounding the possibility 
of a trapdoor in the code of a widely used web 
server. Code investigations revealed that instead 
of a trapdoor^, the code contained disparaging re¬ 
marks about corporate competitors and well as vi¬ 
olations of company coding standards. The fact 
remains, however, that when rumors of the trapdoor 
were initially published, few believed that artifices 
of this type were possible in such a popular soft¬ 
ware product. (However, millions of users do not 
eliminate the problem of low integrity.) 

In his Turing Prize Eecture, Ken Thompson de¬ 
scribed a trapdoor in an early version of the Unix 
operating system [18]. The cleverness of the ar¬ 
tifice was evident in that the artifice was inserted 
into the operating system executable code by the 
compiler, which had been modified so that recom¬ 
pilations of the compiler itself would insert the 
trapdoor implantation mechanism into its own exe¬ 
cutable while leaving no evidence of the trapdoor in 
either the source code for Unix or the source code 
for the C-language compiler. The existence of this 
such an artifact in commercial compilers remains a 
subject of speculation. 

2.3 Production Techniques for High In¬ 
tegrity Systems 

To produce a high integrity system, its components 
must be implemented properly and reflect lack of 


trapdoor is an artifact that allows illicit entry into the 
system. 


subversion. Various approaches exist for ensuring 
these characteristics. The primary approaches are 
(1) post development testing; (2) abstract process 
certification such as the Capability Maturity Model 
[2, 15] and ISO 9001 [1]; and (3) rigorous engi¬ 
neering processes [3, 13]. 

There is ample evidence that testing alone is in¬ 
sufficient to ensure against malicious artifices [8]. 
The abstract certification approaches are not spe¬ 
cific to high assurance or high integrity (although 
they can be used to manage a rigorous engineering 
approach), so they are not discussed further. Under 
the managed engineering approach the system is: 

1. thoroughly documented with respect to func¬ 
tionality and correct use 

2. critically tested with respect to its documenta¬ 
tion 

3. critically examined in its source form with re¬ 
spect to its documentation 

4. under strict configuration management during 
its life-cycle 

5. delivered to users with evidence of non¬ 
tampering 

We assert that to understand the behavior of, and 
have confidence in the pedigree of COTS software, 
one must both test the software to validate that it 
behaves the way it is documented and examine its 
code in conjunction with the specifications to verify 
that it is not encoded to do anything else. Addi¬ 
tional assurance against against malicious artifacts 
is provided by the maintenance of strict configu¬ 
ration control, such that all changes to the software 
are accounted for and related to documentation dur¬ 
ing the lifetime of the software. This configuration 
control may encompass all software development 
tools and the development environment itself. 

A mechanism must be in place to ensure that the 
delivery of software from the vendor to customers 
does not provide opportunities for the modification, 
and thus subversion, of the code. This mechanism 
can range from the use of couriers to automated 
techniques. A robust, high integrity public key in¬ 
frastructure can facilitate the trustworthy delivery 
of software. Certified public keys can be used to 
provide digital signatures so that both the source 
and the integrity of electronically transmitted soft¬ 
ware components can be verified. 

Finally, the product must be used correctly (in¬ 
stalled, configured, administrated and operated) to 



perform correctly, and the procedures for proper 
use must be clearly documented (see item 1, 
above), and rigorously followed. Likewise, the sys¬ 
tem must have a suitable security design to be able 
to protect itself and maintain its own integrity dur¬ 
ing operation. 

3 Model Architecture Described 

In this section, we describe a class of potentially 
high assurance multilevel architectures that support 
multilevel security and unmodified COTS produc¬ 
tivity applications while utilizing (primarily) COTS 
components. The architectures in this class are 
characterized as distributed systems consisting of 
the following components: 

• COTS terminals and workstations 

• COTS user interfaces, applications and appli¬ 
cation servers 

• COTS storage devices 

• Multilevel management components 

• TCB extensions 

• COTS network interconnections 

where the components and their relationships are 
described as follows. 

Client terminals or workstations are logically- 
or physically-separate terminals or workstations 
each of which is configured fo operafe af a sin¬ 
gle user securify level af a lime (Ihus differenli- 
aling Ihem from mullilevel workslalions or com- 
parlmenled mode workslalions). Each workslalion 
executes COTS office produclivily applicalions. A 
characlerislic of Ihe clienl terminals and worksla¬ 
lions is lhal Ihey are purged belween user sessions 
al differenl securily levels in order lo achieve objecl 
reuse objeclives, e.g. [13]. Il is worlh noling lhal 
Ihe workslalions may be equipped wilh a plug-in 
hardware componenl lhal can be used lo eslablish a 
Irusled palh from Ihe user lo a high assurance mul¬ 
lilevel componenl on Ihe nelwork. The Irusled palh 
would be used for user idenlificalion and aulhenli- 
calion as well as session level (re)negolialion. The 
workslalion operates al Ihe selected, single, secu¬ 
rily level for Ihe duration of a given session. 

Storage devices may be storage disks or other 
media. More than one security level of data can be 


stored on these devices. For some approaches, mul¬ 
tiple levels of information are stored on the same 
disk, while in others there is one level per disk. 

Multilevel management components consist of 
trusted servers, operating systems, or device man¬ 
agers, and any attendant hardware. These com¬ 
ponents are topographically interposed between 
clients and storage media such that all communica¬ 
tions and data flowing between the client worksta¬ 
tion and the storage media must pass through the 
multilevel management component. The manage¬ 
ment software is responsible for enforcing manda¬ 
tory policies with respect to data on storage de¬ 
vices. 

Data at different security levels can be separated 
logically or physically. In logical approaches, mul¬ 
tilevel device managers ensure that requests for 
data are always bound to a particular security level 
and that policy enforcement is correctly applied to 
data access requests. Naturally, one form of de¬ 
vice manager is a full-blown high assurance trusted 
computing base incorporating a reference valida¬ 
tion mechanism. Alternative managers could pro¬ 
vide more limited functionality. In the case of phys¬ 
ically separate single level storage subsystems, a 
multilevel component might ensure that data access 
requests are shunted to the appropriate subsystem. 
Clearly, not all architectures relying upon physical 
separation of storage media will be able to support 
“read down” functionality (e.g., where a user ses¬ 
sion at a high security level can read data at a lower 
level) without gross covert backchannels. 

When components are separated from the mul¬ 
tilevel management component by network con¬ 
nections, there will generally need to be a “TCB 
extension” associated with the component to reli¬ 
ably identify the component and its session level to 
the multilevel management component. 

COTS user interfaces, applications and appli¬ 
cation servers are either commercial products or 
freeware. COTS system applications provide use¬ 
ful user-level functionality, such as office produc¬ 
tivity programs and database management services. 
Application servers may provide system applica¬ 
tion functionality to remote (e.g., “thin”) clients. 
User interface applications translate user requests 
to the system application. System applications may 
be modified to be “multilevel aware” in their inter¬ 
actions with the Multilevel Management Compo¬ 
nent, such that they can return advisory markings 
to clients (user interface applications), or they can 
be purely single level [9]. 




Figure 1: Single Process Architecture. (Network 
Connections are degenerate.) 

The last component of our architecture is the 
COTS network connection. These are logically or 
physically separate single level wires used for com¬ 
munication between other components. In some 
cases they may multiplex transmissions at differ¬ 
ent security levels on the same physical medium. 
In this case, cryptography may he used to trans¬ 
form information at various security levels to that 
of the transmission medium. Often different cryp¬ 
tographic keys are used for different levels. 

3.1 Example Architectures 

In this section we descrihe several examples of the 
model architecture. We make no judgment or rep¬ 
resentation as to the adequacy of systems huilt to 
these architectures to enforce their declared or im¬ 
plied security policies. 

A non-distrihuted instantiation of the model ar¬ 
chitecture is shown in Figure 1. In this layout, the 
architecture is process internal, where the lowest 
layer (e.g., “ring”) of the process is a multilevel 
kernel, with an application server (e.g., multilevel- 
aware RDBMS) and application in higher layers. 
Examples of this version of the architecture are 
the Seaview project [7, 12], and “Purple Penelope” 
[16] (this includes a degenerate case of an multi¬ 
level management component). 

A simple distributed instantiation is shown in 
Figure 2. Here, there are logically separate single- 
level workstations connected by a switch to differ¬ 
ent single level data-management subsystems. An 
example of this version of the architecture is that of 
the Starlight project [5], which is designed to allow 
low confidentiality to flow through the switch to 



Figure 2: Switch-Based Architecture. 


high sessions. The third instantiation of the model 
architecture is shown in Figure 3. In this layout, 
there are logically separate single level terminals 
(multiplexed by purging of state between session- 
level changes) connected via TCB extensions to 
multilevel aware application server(s) and then to 
the multilevel component. An example of this ver¬ 
sion of the architecture is that of the NPS MLS 
LAN project [10]. 



Ligure 3: Distributed Multilevel Server Architec¬ 
ture 




4 The Integrity Problem 

In a system of components such as shown in Fig¬ 
ures 1, 2 and 3, a centralized component that con¬ 
trols access to a set of protected objects can enforce 
a confidentiality policy on those objects with re¬ 
spect to the actions of other system components. 
Specifically, if the protected objects are partitioned 
into protection domains, this type of enforcement 
can ensure that data from high confidentiality do¬ 
mains does not exfiltrate to low confidentiality do¬ 
mains (other than, perhaps, through covert chan¬ 
nels). However, this does not mean that high in¬ 
tegrity data can be managed and protected by such 
a system. Rather, the integrity of data managed by 
a system can be no greater than the greatest lower 
bound {GLB)^ of the integrity of all of the system 
components that may modify the object. This is 
the case whether or not the system enforces Biba 
integrity (or some other data or program [17] in¬ 
tegrity policy). 

If the system in question does not enforce an in¬ 
tegrity policy, then high-integrity input data may be 
corrupted by low-integrity components in the sys¬ 
tem. This degradation is possible because the low 
integrity component may modify an object in an 
incorrect way, so modified objects take on the in¬ 
tegrity of the greatest lower bound of the integrity 
of the modifying component and the original in¬ 
tegrity of the object. Essentially, objects modified 
by low integrity components become low integrity 
objects. 

On the other hand, if the system enforces an in¬ 
tegrity policy correctly, then it will restrict the input 
of writable data to be only those objects whose 
integrity labels are less than or equal to the in¬ 
tegrity of the least trusted system component that 
may modify the object. This is due to the integrity 
policy restriction that prevents integrity “write up” 
(i.e., a subject may not modify an object that has 
higher integrity). 

Thus, in either case, the system is limited to 
maintaining data that is at or below the integrity 
level of its least trusted component. To illustrate 
this limitation, if a system consists of these compo¬ 
nents, all of which may modify user data: 

• a medium integrity client application 

• a low integrity COTS operating system 

"'We use greatest lower bound, rather than “minimum,” be¬ 
cause some integrity labels may not be comparable, meaning 
that the labels form a partial, rather than linear, ordering. 


• a high integrity TCB Extension 

• a high integrity TCB 

• and a medium integrity application protocol 
server 

Then the limit of integrity that the system can 
maintain is the GLB of {medium, low, high, high, 
medium) — low. 

5 Conclusion and Discussion 

We have shown that a system can only manage 
and protect data whose integrity is at or below 
that of its lowest integrity component. The hy¬ 
brid security architecture (HSA) systems discussed 
here contain COTS components through which all 
user data flows and which have “low assurance” 
integrity. Therefore, HSA systems are only capa¬ 
ble of maintaining “low assurance” data. These 
systems should not be used in automated informa¬ 
tion processing environments where there are high- 
integrity data requirements. 

Many organizations have a “good enough” atti¬ 
tude regarding data security in multi-user environ¬ 
ments, whereby the marketplace of commercially- 
available security solutions dictates the level of 
security provided to customer and corporate data. 
Eosses associated with data security failures are 
considered part of the cost of doing business and 
are factored into customer pricing as well as cor¬ 
porate tax strategies. Nevertheless, each organiza¬ 
tion must make strategic decisions regarding which 
corporate and customer assets to expose to these 
shared environments. There is increasing compet¬ 
itive pressure for businesses to open their books 
to internet and other data-sharing environments. 
We expect that one impact of this paper will be 
to increase the level of understanding, and help 
quantify, the level of trust regarding data integrity 
that one should place in network/computer archi¬ 
tectures that are based on COTS components. 

One might ask if protection of high integrity data 
is ever achievable. The answer is yes, but only 
in architectures that prevent low-assurance compo¬ 
nents from modifying user data. An example is 
a client-server architecture where both client and 
server are of high integrity, and the data is protected 
(e.g., through carefully constructed protocols with 
high quality encryption) from modification when 
transiting low integrity portions of the network. 
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